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SYSTEM AND METHOD FOR PROVIDING INDICATION OF MAXIMUM TELESERVICE 
PAYLOAD SIZE IN A WIRELESS COMMUNICATION NETWORK 



1 , Field of the Invention 

This invention relates to teleservice messaging in a wireless communication network. 
More particularly, the invention concerns a system and method for providing an indication of 
maximum teleservice payload size to a teleservice message sending entity in order to avoid 
resegmentation and retransmission delays. 

2. Description of the Prior Art 



CROSS-REFERENCE TO RELATED APPLICATIONS 



Not Applicable 



STATEMENT REGARDING FEDERALLY SPONSORED 



RESEARCH OR DEVELOPMENT 



Not Applicable 



BACKGROUND OF THE INVENTION 



Teleservice messagmg is a form of communication that allows information payloads (e.g. 
displayable text, graphics, executables, etc.) to be sent to mobile wireless communication devices 
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(e.g., cellular telephones) in manageable form. This type of messaging can be found in many 
species of wireless telecommunication systems, including those designed according to the 
TIA/EIA-41-D standard, the IS-2000 standard, the GSM standard, the UMTS standard, the IMT- 
2000 standard, and others. When a Mobile Station (MS), such as a wireless telephone, a wireless 
Personal Digital Assistant (PDA) or any other device capable of disseminating teleservice 
messages, is sent teleservice messages containing a payload by a network sending entity, such as 
a Short Message Service (SMS) Center (SMSC), a Message Center (MC), a Wireless Application 
Protocol (WAP) Server, or any other content provider, no regard is given to payload size 
constraints of the network receiving entities that serve the MS, such as the Mobile Switching 
Center (MSC), the Base Station (BS), or other entities. If one (or more) of the network receiving 
entities cannot handle the payload size, the network sending entity must be informed of the 
problem, and it must then resegment the payload into smaller information units and resend them. 
This causes delay and needlessly ties up network resources. 

Accordingly, a solution to the forgoing problem is required that enables teleservice 
payloads to always be sent in information unit sizes that can be accommodated by network 
receiving entities, such that message resegmentation and retransmission due to excessive payload 
size are avoided. 



The foregoing problems are solved and an advance in the art is obtained by a novel 
system and method for providing improved teleservice messaging to a mobile station in a 
wireless communication network. In accordance with the invention, an indication is provided to 
a network sending entity of the maximum teleservice payload size that can be sent by the 
network sending entity to the mobile station via network receiving entities serving the mobile 
station. The payload size indication is utilized by the network sending entity to format the size 
of teleservice messages sent by the network sending entity to the mobile station via the network 
receiving entities, such that resegmentation and retransmission are avoided. 



SUMMARY OF THE INVENTION 



Network sending entities (e.g. SMSCs, MCs, WAP servers, etc.) that send teleservice 
layer messages containing a payload (e.g., displayable text such as SMS messages, displayable 



text and graphics such as WML (WAP Markup Language) documents, and executables such as 
WAP Java applets, etc.) can thus be advised of the maximum payload size (e.g., in bits, bytes, 
data units, etc.) that can be handled by network receiving entities in the wireless network that 
serve a mobile station (e.g., MSCs, BSs, etc.), on a per message basis. This information is used 
by the network sending entity to appropriately segment the total payload into manageable 
packages (at the teleservice layer) prior to sending them on to the network receiving entities. 
This enables efficient use of transmission media and avoids retransmissions of correctly sized 
packages which otherwise may need to be done by trial and error. 

In preferred embodiments of the invention, the payload size indication is provided from 
one of the network receiving entities to the network sending entity. Most preferably, the payload 
size indication is provided from one of the network receiving entities to the sending network 
entity via a database associated with the mobile station. The receiving network entity providing 
the payload size indication could be an MSG acting as a voice communication switch on behalf 
of the mobile station. If data communication is involved, the receiving network entity sending 
the payload size indication could be a Mobile Data Intermediate System (MDIS) or a Serving 
GPRS Support Node (SGSN). The database could be the mobile station's Home Location 
Register (HLR). 

The payload size indication is preferably provided from one of the network receiving 
entities to the database as a message parameter during standard registration message exchange 
between the network receiving entity and the database during operations of the wireless network. 
Similarly, the payload size indication is preferably provided from the database to the network 
sending entity as a message parameter during routine registration message exchange between the 
database and the network sending entity. 

BRIEF DESCRIPTION OF THE DRAWING 

The foregoing and other features and advantages of the invention will be apparent from 
the following more particular description of preferred embodiments of the invention, as 
illustrated in the accompanying Drawing, in which: 
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Fig. 1 is a functional block diagram showing a wireless communication system 
constructed in accordance with the invention; 

Fig. 2 is an information flow diagram showing an AuthenticationRequest operation using 
a maximum teleservice payload size indicator in accordance with the invention; 

Fig. 3 is an information flow diagram showing a FeatureRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 4 is an information flow diagram showing a LocationRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 5 is an information flow diagram showing an OriginationRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 6 is an information flow diagram showing a QualificationRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 7 is an information flow diagram showing a RegistrationNotification operation using 
a maximum teleservice payload size indicator in accordance with the invention; 

Fig. 8 is an information flow diagram showing an SMSNotification operation using a 
maximum teleservice payload size indicator in accordance with the invention; 

Fig. 9 is an information flow diagram showing an SMSRequest operation using a 
maximum teleservice payload size indicator in accordance with the invention; and 

Fig. 10 is an information flow diagram showing a TransferToNumberRequest operation 
using a maximum teleservice payload size indicator in accordance with the invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Turning now to the figures, wherein Uke reference numerals represent like elements in all 
of the several views. Fig. 1 illustrates a functional representation of an exemplary wireless 
communication system 2 constructed in accordance with preferred embodiments of the invention. 
Fig. 1 is intended to be generic in nature and not limited to any particular wireless network 
standard. Indeed, the wireless system 2 may be implemented using any of the wireless network 
standards now in existence, such as TIA/EIA-41-D, IS-2000 or GSM, or which may be adapted 
in the future, such as UMTS, IMT-2000 or the like. Moreover, as described below, the wireless 
system 2 may be adapted to carry voice traffic, data traffic or both. 

As is known in the art, the wireless system 2 includes a plurality of wireless service areas, 
each of which is managed by the usual wireless network serving entities, including an MSG and 
one or more BSs. Fig. 1 illustrates two wireless service areas that are respectively managed by 
the MSG 4 and the MSG 6. Associated with each MSG are the usual Home Location Register 
(HLR), Visitor Location Register (VLR), Authorization Genter (AG) and Equipment Identity 
Register (EIR), all of which, with the exception of the invention-related enhancements described 
below, are conventional in nature. In Fig. 1, it will be seen that the MSG 4 is associated with an 
HLR 8, a VLR 10, an AG 12 and an EIR 14, and that the MSG 6 is associated with an HLR 9, a 
VLR 11, an AG 13 and a EIR 15. 

As is further knovra in the art, each MSG supports a plurality of BSs, each of which 
conducts wireless communications in an assigned geographic coverage area commonly referred 
to as a cell. Fig. 1 illustrates two such BSs; namely, the BS 16 connected to the MSG 4 and the 
BS 18 cormected to the MSG 6. Each BS includes radio transceiver equipment for 
communicating in conventional fashion over an air interface with a plurality of MSs, which 
could be cellular telephones, wireless computing devices such as PDAs, or other radio 
communication equipment. Fig. 1 illustrates two such MSs; namely, the MS 20 communicating 
with the BS 16 and the MS 22 communicating with the BS 18. 



In the wireless network 2, the MSCs 4 and 6 act as switching nodes for respectively 
communicating voice traffic on behalf of the MSs 20 and 22 over the circuit-switched PSTN 23. 
In association with the usual data network gateway equipment (not shown) the MSCs 4 and 6 
may also communicate voice traffic (VoIP) over the public Internet 3 1 . The wireless network 2 
may also be adapted to carry data traffic (e.g., over the Internet 31) on behalf of MSs that are 
equipped for wireless data communication. There are several wireless data standards in use 
today, with the most prevalent being the Cellular Digital Packet Data (CDPD) and General 
Packet Radio Service (GPRS) standards. 

The wireless network 2 can be adapted to implement the CDPD standard by adding a 
plurality of Mobile Data Base Stations (MDBSs) and a Mobile Data Intermediate System switch 
(MDIS) in one or more of the wireless service areas. These entities are analogous to, and are 
typically associated with, the existing voice-oriented BSs and MSCs. The MDBSs communicate 
with the MSs over an air interface and the MDISs provide connectivity to a data network, such as 
the Internet 31. Thus, in Fig. 1, the wireless network 2 may include an MDBS 24 associated 
with the BS 16, and an MDBS 26 associated with the BS 18. Likewise, the wireless network 2 
may include an MDIS 28 associated with the MSG 4 and an MDIS 30 associated with the MSG 
6, each of which connect to the Internet 31. In combination, the MDBS 24 and the MDIS 28 
provide data communication support on behalf of the MS 20, while the MDBS 26 and the MDIS 
30 provide data communication support on behalf of the MS 22. 

The wireless network 2 can be adapted to implement the GPRS standard by adding a 
plurality of Serving GPRS Support Nodes (SGSNs) and a Gateway GPRS Support Node 
(GGSN) in one or more wireless service areas. Each SGSN is typically connected to a voice- 
oriented or packet data-oriented BS and MSG, and each GGSN is usually connected to a data 
network, such as the Intemet 3 1 . Thus, in Fig. 1, the wireless network 2 may include an SGSN 
32 and GGSN 34 associated with the wireless service area managed by the MSG 4, and an SGSN 
36 and GGSN 38 associated with the wireless service area managed by the MSG 6. In 
combination, the SGSN 32 and the GGSN 34 provide data communication support on behalf of 
the MS 20, while the SGSN 36 and the GGSN 38 provide data communication support on behalf 
of the MS 22. 
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As is conventional, the MSs 20 and 22 have teleservice messaging capabiUty, which 
allows them to retrieve teleservice pay loads from a Network Sending Entity (NSE) 40 that 
communicates with the MSs via receiving network entities in the wireless network 2, such as the 
MSCs and the BSs. The NSE 40 could be any network sending entity supporting any service 
that requires the sending of large blocks of information requiring segmentation in order to be 
delivered to the MSs. For example, the teleservice messages sent by the NSE 40 could include 
SMS messages, Unstructured Supplementary Service Data (USSD) messages, Circuit Switched 
Data (CSD) messages, CDPD messages and GPRS messages. More specifically, one kind of 
network sending entity that could be represented by the NSE 40 is an SMS Message Service 
Center (SMSC) sending SMS messages. An SMSC acting on behalf of the MSs 20 and 22 could 
provide teleservice messages to the MSs that pertain to conmiunications received from the PSTN 
23 (e.g., voice mail messages), the Internet 31 (e.g., email messages), and/or from other sources, 
such as a paging network 42 (e.g., paging messages). These messages would typically be 
provided to the MSs 20 and 22 via the intelligent network (e.g., SS7) portion 44 of the PSTN 23. 
Another network sending entity that could be represented by the NSE 40 is an Over-The- Air- 
Function (OTAF) used for provisioning wireless service (e.g., activating subscribers), 
downloading Preferred Roaming Lists (indicating the systems from which a roamer would prefer 
to receive service), and other fixnctions. Still another network sending entity that could be 
represented by the NSE 40 is a WAP server operating in accordance with the WAP standard. 

In general, the network receiving entities that serve the MSs will vary depending on the 
message source and type. Circuit-based teleservice layer messages would normally be 
distributed to the MSs through the MSCs and the BSs. Packet-based teleservice layer messages 
may be distributed to the MSs through the MDISs (for CDPD data), or the SGSNs (for GPRS 
data), together with the BSs. 
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As stated, the network sending entities used in prior art wireless network systems format 
teleservice layer messages without knowledge of payload size constraints in the network 
receiving entities serving the mobile stations. The solution provided in accordance with 
preferred embodiments of the present invention entails the inclusion of an attribute in standard 
wireless network registration messages (e.g., a RegistrationNotification message according to the 
TIA/EIA-41-D standard) that allows the network sending entity to determine the maximum 
teleservice payload size that can be handled by the receiving network entities (e.g., MSCs, BSs, 
etc.). These standard registration messages that are modified to incorporate a teleservice payload 
size attribute include (1) registration messages that are first exchanged between a network 
receiving entity serving an mobile station (e.g., an MSG) and a database associated with the 
mobile station (e.g., an HLR), and (2) registration messages that are thereafter exchanged 
between the database and the network sending entity. More particularly, the first group of 
G registration messages provide the teleservice payload size information from the serving network 
5 receiving entity to the database, where the information is stored, and the second group of 
^5 registration messages provide the teleservice payload size information from the database to the 
□ network sending entity. The network sending entity will then be able to use this information on 
large messages in order to segment them into units of appropriate size. 

To illustrate, consider the wireless telecommunication s>^tdn of Fig. 1 wherein network 
V I entities, such as the MC 32, an MSG 4 or 6, a BS 16 or IS^UmRLR 8 or 9 (among others) are 

]i involved in providing voice services to a network sub^fiber operating one of the MSs 20 or 22. 

O In that case, when the subscriber powers-on the Mi^roams to a new service area (MSG/BS), 
originates a call, responds to a page for an ipemning call, or in any other way accesses the 
wireless network 2, a registration proc^jmypically ensues. Registration results in the serving 
MSG informing the HLR assigned/tD the MS of the MS's presence in its sphere of influence. 
The HLR retains this informafim and will in turn forward the information upon request to the 
MG 32, so that the MG c^iUbrward incoming messages to the target MS 20 or 22, as in the case 
of mobile-terminated^MS. 



Following are specific examples illustrating how teleservice payload size information can 
be provided to an NSE. All of the examples below are based on conventional registration 
messages currently in use according to the TIA/EIA-41-D wireless network intersystem operators 
standard. Appended to certain of these messages is a TS_DataSize parameter that indicates the 
maximum teleservice payload size that can be handled in a wireless service area managed by an 
MSG, an MDIS or a GGSN. Advantageously, no special payload size queries or processing are 
required. The teleservice payload size information, which is equipment-specific, can be input at 
system deployment time by a system administrator into a parameter database of the type 
conventionally associated with MSCs, MDIS and GGSNs for storing basic operating 
information. 

In the following examples, the set of parameters shown in addition to the TS_DataSize 
attribute are not necessarily inclusive. They are set forth for the purpose of illustration only 
based on existing standards. Persons skilled in the art will appreciate that the parameters shown 
may be augmented (or altered) in the future. 

Example 1 — Authentication On Initial Access 

This operation scenario describes the successful use of an AuthenticationRequest 
operation to authenticate an MS, which is attempting initial access to a serving MSG. The MS is 
aware that authentication is required on all system accesses. The result of the operation is to 
allow access. As shown in Step "a" of Fig. 2, during the initial access attempt by the 
authentication-capable MS (not shown), the serving MSG 50 sends an AUTHREQ message to a 
serving VLR 52. This message contains the following parameters, all of which are conventional 
save for the TS_DataSize parameter, which is added in accordance with the invention: 




Parameters 


Usage 


Type 


AuthReqParameters 1 : 


Set of parameters in AUTHREQ: 




[MIN] 


Served MS MIN. 


R 


[ESN] 


Served MS ESN. 


R 




serving MoU iVLociL/. 


i> 




oerving jviou inciuae it 00/ 
carriage services are used. 




[SystemCapabilities] 


Auinenu canon capaDiuues or oervmg 
MSC. 


J> 

JV 


[SystemAccessType] 


lype 01 sysicm access — regisiraiion. 


1? 

JV 


[Term i nalTy p e] 


iQeniiiies ine rauiu irecjucncy inicriacc 
standard supported by the associated MS 


T? 
IV 


RAND 


Random number derived from MS-provided 
RANDC by Serving MSC. 


R 


AUTHR 


Authentication result provided by MS. 


R 


COUNT 


Value of CallHistoryCount provided by MS. 


R 


TS DataSize 


Maximum size of Teleservice pavload 


0 









As shown in Step "b" of Fig. 2, the VLR 52 sends an AUTHREQ message to an HLR 54 
associated with the MS. The parameters are the same as in Step "a" of Fig. 2, but include the 
following conventional modifications: 



Parameters 


Usage 


Type 


[Sy stemCapabil ities] 


Authentication capabiHties of Serving 


R 




VLR. 




[PC_SSN] 


Serving VLR PC_SSN. Include if SS7 


0 




carriage services are used. 





As shown in Step "c" of Fig. 2, the HLR 54 forwards the AUTHREQ message to an AC 
56 associated with the MS. The parameters are the same as in Step "b" of Fig. 2. 

In Step "d" of Fig. 2, the AC 56 determines that the MS should be allowed access and 
sends an authreq message to the HLR 54. The message parameters, all of which are 
conventional, are as follows: 




Parameters 


Usage 


Type 


AuthReqParameters2: 


Set of parameters in authreq: 




[CallHistoryCount] 


Event counter used for clone detection. 
Included if SSD is shared. 


0 


[RANDSSD] 


Random number for SSD generation. 
Included if a SSD update and a Unique 
Challenge to the MS should be initiated 
by the serving system. 


0 


[RANDU] 


Random number generated by AC to 
produce AUTHU, Included if a Unique 
Challenge to the MS should be initiated 
by the serving system. 


0 


[AUTHU] 


Expected MS response to Unique 
Challenge Order as calculated by AC. 
Included if a Unique Challenge to the MS 
<!lirnilfl he initiated bv the serving svstem. 


0 


[UpdateCount] 


Indicates that the COUNT update 
procedure should be initiated by the 


0 


NewSSDInfo: 


New SSD information: 




[Authentication- 
AlgorithmVersion] 


Include if SSD included to select 
authentication algorithm other than 
default. 


0 




New value of VT.R and AC shared secret 
data. May be included if the 
SystemCapabilities of the VLR include 
"CAVE execution" and AC 
administration policies allow distribution 
of the SSD. 


0 


NOSSD 


Indicates that previously provided SSD is no 
longer valid and should be discarded. 


0 



In step "e" of Fig. 2, the HLR 54 forwards the authreq message to the VLR 56. The 
parameters are the same as for step "d" of Fig. 2. 

In step "f of Fig. 2, the serving VLR forwards the authreq message to the MSG 50. The 
parameters are the same as in step d of Fig. 2, except that the SSD, AAV and NOSSD parameters 
are not included, as is conventional. 



Example 2 - Direct FeatureReauest With Call Routing 



0^9^ This operation scenario describes a normal FeatureRequest^o^ration when the response 
from an HLR includes instructions for the serving system to^set up a call. As shown in step "a" 
of Fig. 3, a feature code string (i.e., a string^ofdigits^including a feature code) received from an d 
MS (not shown) are included in a FEAJREQ message and sent by a serving MSG 60 to an HLR 
62 associated with the MS^-h^message parameters, which are otherwise conventional, include 
a TS_DataSize parameter in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN. 


R 


BILLID 


Call ID. Used for billing and redirection 
purposes when FEATREQ results in call 
routing. 


R 


DGTSDIAL 


Feature code string entered by served MS. 


R 


SENDERIN 


Identification number of the sending node. 


R 


TRANSCAP 


Indicates the serving system's transaction 
capability at the current time. 


R 


OTFI 


Indicates the current feature activation 
status. 


0 


TS DataSize 


Maximum size of Teieservice Davload 


O 




In step "b" of Fig. 3, the HLR 62 determines the appropriate feature treatment based on 
the received information and returns this in a featreq message. In this scenario, the response 
from the HLR 62 includes instructions for the serving system to set up the call. The featreq 
message has the foUov^ing conventional parameters: 



Parameters 


Usage 


Type 


FEATRESULT 


Feature request result. 


R 


TERMLIST 


Call termination information. 


R 


ACTCODE 


Treatment for served MS. If not included, 
trpatmpnt i«i ha<ied on FEATRESULT 
value. 


0 


/VJN INITIO 1 


T iot" tnnf^c nr iintir»iinr*<^mAntc tn nlflv Tt 
l^lsL \)l lUllCa UI alLllUUli^^dlldllo lU yiay. i.i 

not included, announcement is based on 
FEATRESULT value. 


0 


DMHData: 


Data for DMH recording purposes: 




[DMH_AccountCode- 
Digits] 


Include if applicable. 


0 


[DMH_AltemateBillin 
gDigits] 


Include if applicable. 


0 


[DMHBillingDigits] 


Include if applicable. 


0 


[MobileDirectory- 

i>l UlliUCl J 


Include if applicable. 


o 


GRPINFO 


Information associated with group routing. 


o 


OTFI 


Indicates the current feature activation 
status. 


o 


PACAIND 


Indicates PACA priority level. 


0 


CARDGTS 


Calling subscriber's PIC. Include if 

applicable and if not specified within the 
TerminationList parameter. 


o 


ROUTDGTS 


Special routing instructions. Include if 
applicable and if not specified within the 
TerminationList parameter. 


0 


TERMTRIG 


Indicates active termination trigger points. 


o 



Example 3 - Successful Location Request 

This operation scenario describes a LocationRequest operation when the call treatment is 
to route the call to a PSTN directory number. As shown in step "a" of Fig. 4, an originating 
MSG 70 sends a LOCREQ message to an HLR 72 associated with the MS (not shown). This 
association is made through the dialed MS address digits (which may not be the MIN). The 
message parameters, which are otherwise conventional, include a TS_DataSize parameter in 
accordance with the invention, as follows: 



Parameters 


Usage 


Type 


BILLID 


Call ID. Used for billing and redirection 
purposes when LOCREQ results in call 
routing. 


R 


OrigID: 


Originating MSC's identification information: 




[MSCID] 


Originating MSC MSCID. 


R 


[PC_SSN] 


Originating MSC PC_SSN. Include if SS7 
carriage services are used. 


0 


[SystemMyTypeCode] 


Originating MSC vendor identification. 


MBC 


DGTSDIAL 


Digits identifying called party. 


R 


TRANSCAP 


Indicates the originating system's transaction 
capability at the current time. 


O 


TAT 


TerminationAccessType identifying special 
access situations. Include if applicable. 


0 
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TS DataSize 



Maximum size of Teleservice pay load 



O 



In step "b" of Fig. 4, the HLR 72 determines that the call shall be routed to a PSTN 
directory number and returns this information to the Originating MSG in the locreq message, 
having the following conventional parameters: 



Parameters 


Usage 


Type 


MIN 


Called MS MIN. 


R 


ESN 


Called MS ESN. 


R 


MSCID 


Serving MSC*s MSCID. 


R 


ANNLIST 


List of tones or announcements to play. If 
not included, announcement is based on 
other parameters in response. 


0 


PSTNRoutinglnfo: 


Call routing information: 




[TerminationList] 


Network termination information. Include 
if TerminationList is allowed. 


0 


[Digits(Destination)] 


PSTN DN for use in call routing. Include 
if TerminationList is not allowed. 


0 


[RoutingDigits] 


Special routing instructions. Include if 
applicable and if not specified within the 
TerminationList parameter. 


O 


[Digits(Carrier)] 


Called subscriber's PIC. Include if 
appiicaDie ano ii not specinea wiinm ine 
TerminationList parameter. 


O 


DMHData: 


Data for DMH recording purposes: 




[DMH_AccountCode- 
Digits] 


Include if applicable. 


0 


[DMHAltemateBiilin 
gDigits] 


Include if applicable. 


0 


[DMH_BillingDigits] 


Include if applicable. 


O 


[MobileDirectory- 
Number] 


Include if applicable. 


0 


[DMH_Redirection- 
Indicator] 


Include if applicable. 


R 
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Example 4 - Successful OriginationRequest 

This operation scenario describes an OriginationRequest operation when a call 
origination request is successful. As shown in step "a" of Fig. 5, dialed digits are included in 
ORREQ message and sent by a serving MSG 80 to an HLR 82 associated with an MS (not 
shown). The message parameters, which are otherwise conventional, include a TS_DataSize 
parameter in accordance with the invention, as follows: 



Parameters 


usage 


lype 


"OTT T T"r\ 

BILLID 


L^aii LU. usee lor Dining ana reaireciion 
purposes when ORREQ results in call 
routing. 


rv 


MIN 


Served MS MIN. 


R 


ESN 


berveo Mo coin. 


rv 


MSCID 


Serving MSG MSCID. 


R 


PC_SSN 


Serving MSG PC_SSN. Include if SS7 
carriage services are used. 


0 


DGTSDIAL 


Digits, entered by served MS, which identify 

lllC CallCU pdiiy. 


R 


ORIGTRIG 


Indicates the origination trigger responsible 
for the operation invocation. 


R 


TRANSCAP 


Indicates the Serving MSC's transaction 
capabilities at the current time. 


R 


TS DataSize 


Maximum size of Teleservice pavload 


O 



y^'Tl O ^ The HLR 82 determines that the originatiori^T^^uest be approved and returns routing 
^ / O instructions in the orreqeq niessage^Girtalningthe following conventional parameters: 



Parameters 


Usage 


Type 


TERMTRIG 


Termination trigger points currently active 
for the MS. Include if applicable. 


. O 


ACTGODE 


Include if action to be performed is not 
implied through presence of other 
parameters. 


O 


ANNLIST 


List of tones or announcements to play. If 
not included, announcement is based on 
other parameters in response. 


0 


Routinglnfo: 


Call routing information: 




[TerminationList] 


Gall termination information. 


R 


[RoutingDigits] 


Special routing instructions. Include if 
applicable and if not specified within the 
TerminationList parameter. 


0 


[CarrierDigits] 


Galling subscriber's PIC. Include if 
applicable and if not specified within the 
TerminationList parameter. 


O 


DMHData: 


Data for DM/ recording purposes: 





TDMH AccountCode- 
Digits] 


Include if aoolicable. 


0 


[jJiVLri Aitematersiiiin 
gDigits] 


inClUGc 11 appiICaDlc. 


o 


[DMHBillingDigits] 


Include if applicable. 


\J 


[DMH_Redirection- 
Indicator] 


Include if applicable. 


R 


[MobileDirectory- 
Number] 


Include if applicable. 


0 



Example 5 - Successful OualificationRequest 

This operation scenario describes a QualificationRequest operation when authorization is 
confirmed and no profile is requested. As shown in step "a" of Fig. 6, after determining that a 
roaming MS (not shown) is within its service area, a serving MSG 90 sends a QUALREQ 
message to its VLR 92. The MSG 90 may detect the MS's presence through autonomous 
registration, call origination, call termination (i.e. a page response following a call to the roamer 
port) or a service order. The message, which is otherwise conventional, includes a TS_DataSize 
parameter in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN. 


R 


MSCID 


Serving MSC MSCID. 


R 


MYTYP 


Serving MSC vendor identification. 


MBC 


QUALCODE 


Type of request = validation only. 


R 


SYSACCTYPE 


Indicates the type of system access. 


R 


TRANSCAP 


Indicates the serving system's transaction 
capability at the current time. 


R 


TS DataSize 


Maximum size of Teleservice pavload 


O 



If the MS had previously registered with the MSC 90 (or any other MSC within the 
domain of the VLR 92), the VLR 92 may take no further action other than to record the identity 
of the MSC 90 currently serving the MS and proceed to step "d" of Fig. 6. If the MS is unknown 
to the VLR 92, or if the information requested by the MSC 90 is not available at the VLR 92, the 




VLR 92 sends a QUALREQ message to an HLR 94 associated with the MS, as shown in step 
"b" of Fig. 6. The message parameters are the same as in step "a" of Fig. 6, and also include the 
following additional conventional parameters: 



Parameters are as in Step-a, with the following modifications: 


Parameters 


Usage 


Type 


MYTYP 


VLR vendor identification. 


MBC 



In step "c" of Fig. 6, the HLR 94 determines that authorization can be granted to the MS 
and returns this indication to the VLR 92 in a qualreq message, containing the following 
conventional parameters: 



Parameters 


Usage 


Type 


AUTHPER 


Authorization confirmed indication with 
period of authorization. 


R 


HLRID [MSCID] 


HLR MSCID to key MS record against for a 
subsequent 

UnreliableRoamerDataDirective. 


R 


MYTYP 


HLR vendor identification. 


MBC 



In step "d" of Fig. 6, the VLR 92 sends a qualreq message to the MSG 90 containing the 
same parameters as in step "c" of Fig. 6, with the following conventional modifications; 



Parameters 


Usage 


Type 


HLRID [MSCID] 


HLR MSCID. Include if received in Step-c. 


O 


MYTYP 


VLR vendor identification. 


MBC 



Example 6 - Successful RegistrationNotification 

This operation scenario describes a RegistrationNotification operation when confirmed at 
an HLR. A serving MSG determines that a roaming MS is within its service area. The serving 
MSG may detect the MS's presence through autonomous registration, call origination, call 
termination (i.e., a page response following a call to the roamer port) or a service order. As 



shown in step "a" of Fig. 7, the serving MSG 100 sends a REGNOT message to its VLR 102. 
The message, which is otherwise conventional, contains a TS_DataSize parameter in accordance 
with the invention, as follows: 



Parameters 


Usage 


Type 


IDInfo: 


Set of identification parameters in 




[iVIllNJ 


oCrVcU IV1l5 iVUlN. 


R 




Served FW 


R 




Serving MSG MSCID 


R 


[PC_SSN] 


Serving MSG PG_SSN. Include if SS7 

i^di 1 idgc at/1 viwto ai\/ uo^u. 


0 


[LocationArealD] 


For paging served MS. Include if 

ctvciiiauit/. 


0 


[SystemMyTypeCode] 


Serving MSG vendor identification. 


MBG 


QUALCODE 


Type of qualification required. 


R 


SYSACCTYPE 


Type of system access. 


R 


'I'll A XTCO A T> 


System's transaction capability 




TERMTYP 


Identifies the radio frequency interface 
. sianaaru supponeu oy inc aaaociaicu ivio 


R 


AVTYP 


Indicates MS is unavailable for normal call 
delivery, if applicable. 


0 


SMSADDR 


Temporary routing address of SMS 
subscriber, if applicable. 


0 


AuiiLcrror: 


r arameiers inciuueu ii auinciiiiuaLJuii 

parameters were requested by the Serving 
MSG but not received from the MS: 




[SystemCapabilities] 


/VUinenilCallOn l/dpaDlIlllCa Ul ocivmg 

system. 




[ReportType] 


Report of missing authentication 
parameters. 




BORDACC 


Indicates that system access is in a border 
cell, as determined by local procedures. 


0 


TS DataSize 


Maximum size of Teleservice pavload 


0 








Accesslnfo: 


Subscriber's access information. Included if 
system access is in a border cell. 
Includes: 


0 


[ReceivedSignalQuality] 


Raw received signal strength from MS for 
use in multiple access signal strength 
arbitration. 






[ControlChannelData] 


Includes: DCC and CHNO of analog 






access channel for use in multiple access 






detection; 






CMAC for use in signal strength 






arbitration. 




[SystemAccessData] 


Indicates the Serving MSG and cell site 






for use in multiple access detection. 





The VLR 102 determines that either (a) the MS had previously registered with the MSG 
100 (or another MSG within the domain of the VLR) but the MS has been reported inactive by 
the VLR 102, (b) the MS is not known to the VLR 102, or (c) the requested information cannot 
be made available for the indicated MS. Under these conditions, in step "b" of Fig. 7, the VLR 
102 forwards the REGNOT message of step "a" of Fig. 7 to an HLR 104 associated with the MS, 
with the following additional conventional parameters: 



Parameters 


Usage 


Type 


[PC_SSN] 


Serving VLR PC_SSN. Include if SS7 
carriage services are used. 


0 


[MYTYP] 


Serving VLR vendor identification. 


MBC 



The HLR 104 determines that authorization can be granted to the MS. In step "c" of Fig. 
7, it returns the requested information to the VLR 102 in a regnot message containing the same 
parameters as in step "b" of Fig. 7, with the foUov^ing conventional additions and modifications: 



Parameters 


Usage 


Type 


HLRID [MSCID] 


HLR MSCID to key MS record against for a 
subsequent 

UnreliableRoamerDataDirective. 


R 


MYTYP 


HLR vendor identification. 


MBC 



In step "d" of Fig. 7, the VLR 102 forwards the regnot message to the MSG 100 using the 
same parameters as in step "c" of Fig. 7, with the following conventional modification: 




Parameters 


Usage 


Type 


MYTYP 


VLR vendor identification. 


MBC 



Example 7 - Successful SMSNotification 

This scenario describes the successful use of an SMSNotification operation, conveying to 
an SMSC the SMS_Address of an MS-based Short Message Entity (SME). The invoking 
Functional Entity (FE) such as an MSG, an HLR, etc., detects a change of an MS's status or 
location indicating the availability of an MS-based SME. As shown in step "a" of Fig. 8, the 
invoking FE 1 10 may send an SMSNOT message to the responsible SMSC 112. If the FE 1 10 
has a pending request for the address of an MS-based SME, it must respond. The message, 
which is otherwise conventional, includes a TS_DataSize parameter in accordance with the 
.fi invention, as follows: 





Parameters 


Usage 


Type 




NUN 


Used to identify the MS. 


R 




ESN 


Used to identify the MS. 


R 




SMSADDR 


Temporary routing address that can be used 
to deliver one or more short messages to 
the indicated MS. 


R 




TS DataSize 


Maximum size of Teleservice pavload 


O 



As shown in step "b" of Fig. 8, the SMSC 112 confirms the receipt of the address by 
returning an smsnot message to the FE 110. 




Example 8 - Successful. SMSRequest 

^ This scenario describes the successful usepf^SMSRequest operation, resulting in the 
return of the SMS_Address of an MS-b^setf^ME to an SMSC. As shown in step "a" of Fig. 9, 
an SMSC 120 does not havejhe'current network address of the indicated MS-based SME, and it 
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sends an SMSREQ message toward an HLR 112 associ^edwitlrtiie MS (possibly using SCCP 
global title translation of the MIN). Thgumessage parameters are conventional: 



Parameters 


Usage 


Type 


MIN 


Used to identify the MS. 


R 


ESN 


Used to identify the MS. 


0 


SMSNOTIND 


Include if a notification of MS availability is 
not required. 


O 



If the HLR 122 has the current address of the indicated MS-based SME, an smsreq 
message in accordance with step "f of Fig. 9 is sent from the HLR 122 to the SMSC 120. 
Otherwise, as shown in step "b" of Fig. 9, the HLR 122 forwards the SMSREQ message toward 
a VLR 124 serving the addressed MS-based SME. The message parameters are the same as in 
step "a" of Fig. 9. 

In step "c" of Fig. 9, the VLR 124 forwards the SMSREQ message toward an MSG 126 
serving the addressed MS-based SME. The parameters are the same as in step "a" of Fig. 9. 

^ The MSG 126 returns an smsreq message to the VLR 124Jndieafmg the current network 
address that can be associated with the indicated34&^5ased SME. The message parameters, 
which are otherwise conventionaLinehiae^a TS DataSize in accordance with the invention, as 
follows: 



Parameters 


Usage 


Type 


SMSADDR 


Temporary routing address that can be used 
to deliver one or more short messages to 
the indicated MS. 


R 


TS DataSize 


Maximum size of Teleservice oavload 


O 



In step "e" of Fig, 9, the VLR 124 forwards the smsreq message to the HLR 122. The 
parameters are the same as in step "d" of Fig. 9. 

In step "f of Fig. 9, the HLR 122 sends the smsreq to the SMSC 120. The parameters 
are the same as in step "d" of Fig. 9. 



Example 9 - Successful TransferToNumberRequest 

This operation scenario describes a normal TransferToNumberRequest operation. As 
shown in step "a" of Fig. 10, an originating MSG 130 sends a TRANUMREQ message to an 
HLR 132 associated with an MS (not shown), including an indication of the feature responsible 
for redirecting the call (e.g., CFB). The message parameters, which are otherwise conventional, 
include a TS_DataSize parameter in accordance with the invention, as follows: 



Parameters 


Usage 


Type 


BILLID 


Originating BillingID, required to identify 
instances of Flexible Alerting 




MIN 


Served MS MIN. 


R 


ESN 


Served MS ESN. 


R 


MSCIN 


Include for IS-41-C or later. 


0 


MYTYP 


Originating MSG vendor identification. 


MBC 


PIEDREASON 


Identifies reason for the TRANUMREQ. 


R 


TRANSCAP 


Indicates the originating system's 

transaction capability at the current time. 


R 


GRPINFO 


Information associated with group routing. 
Include if available 


0 


LEGINFO 


Identifies a leg in a multiple termination call. 
Include if available. 


0 
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TS DataSize 



Maximum size of Teleservice pavload 



O 



As shown in step "b" of Fig. 10, the HLR 130 determines the forward-to number for 
redirecting the call and returns this to the MSG 130 in a tranumreq message. The parameters of 
this message are as follows: 



Parameters 


Usage 


Type 


Routinglnfo: 


Call routing information: 




[TerminationList] 


Network termination information. Include 
if TerminationList is allowed. 


0 


[Digits(Destination)] 


PSTN DN for use in call routing. Include 
if TerminationList is not allowed. 


O 


[Digits(Carrier)] 


Called subscriber's PIC. Include if 
applicable and if not specified within the 
TerminationList parameter. 


O 


ACTCODE 


Include if action to be performed is not 
implied through presence of other 
parameters. 


0 


ANNLIST 


List of tones or announcements to play. If 
not included, announcement is based on 
other parameters in response. 


O 


1 tivJVl 1 x\l\j 


lerminaiion ingger puinia currcnLiy dL^uvc 
for the subscriber. Include if applicable. 


n 


OKriiNrvJ 


iQeniines me new leg m a muiiipie 

termination call. Include if applicable. 


n 


CNIinfoASCII: 


CNI information including digits parameters 
in ASPTT fnrmnt TnrliiHp as annlicahle' 




[CallingPartyNumber- 
Stringl] 


Calling number digits (network-provided), 
incl. Presentation restriction information. 


0 


[CallingPartyNumber- 
String2] 


Calling number digits (user-provided), 
incl. Presentation restriction information. 


0 


[RedirectingNumber- 
String] 


Redirecting number digits, incl. 
Presentation restriction information. 


o 


[CallingPartySubaddre 

ss] 


Calling number subaddress (user- 
provided). 


0 


[Red irectingSubaddres 
s] 


Redirecting number subaddress. 


o 


RNDGTS 


Redirecting number digits in BCD format. 
May include if call is to be redirected out 
of the Originating MSC. 


0 
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DMHData: 


Data for DAffl^ recording purposes: 




[D]V[H_AccountCode- 
Digits] 


Include if applicable. 


O 


[DMH_AltemateBillin 


Include if applicable. 


O 


[DMH_BillingDigits] 


Include if applicable. 


0 


[DMH_Redirection- 
Indicator] 


Reason for extending the incoming call. 
Include for recording purposes. 


R 


[Mob i leD irectory- 
Number] 


Include if applicable. 


O 



Accordingly, a system and method have been described for providing an indication of 
maximum teleservice payload size in a wireless communication system. While various 
embodiments of the invention have been disclosed, it should be apparent that many variations 
and alternative embodiments could be implemented in accordance with the invention. It is 
understood, therefore, that the invention is not to be in any way limited except in accordance 
with the spirit of the appended claims and their equivalents. 



